…oduct/docs (#4540)

Address all blockers and strong-should-fix items from the three-expert
review on PR #4540. Open questions resolved with consensus positions
baked into the contract.

Schemas
- Fix oneOf discriminator: success arm now carries symmetric not.errors,
  matching the error arm. Mirrors search-brands-response.json convention.
- Per-tool status enum subsets — verify_property excludes pending_review
  and licensed_in/out; verify_trademark excludes pending_review;
  verify_subsidiary excludes licensed_in/out. Each tool's response
  constrains the shared VerificationStatus to its applicable set.
- Add `transferring` to VerificationStatus — M&A in flight is distinct
  from pending_review.
- Drop redundant `license_type` from verify-trademark-response (status
  already carries the licensing relationship).
- Field-name consistency: `context_note` everywhere (verify_subsidiary
  previously had `dispute_reason`).
- `regions` empty-array ambiguity resolved with `"global"` sentinel
  matching request schema.
- Use-case authorization gains a registered starter set (advertising,
  endorsement, retail_listing, editorial, commercial_advertising,
  merchandise_resale) with additionalProperties: boolean for extensions.
- pending_review now REQUIRES expected_resolution_window_days; agents
  MUST transition or flip to unknown past the window.

RFC doc
- Conflict resolution promoted from open question to normative trust
  model. Full table covering all status × crawl-observation combinations.
- Signing key corrected: adcp_use: "response-signing" (not request-signing).
  Per the keys-per-purpose convention.
- "DRM-shaped" stays as analogy; lead framing is "federated authoritative
  verification" — what the spec audience actually wants.
- Motivation honest about what the surface does NOT fix: the sub-brand
  self-publishing problem is relocated, not solved. Partner gets typed
  state instead of silence; brand-side workflow gap remains.
- verify_property reframed: not a bid-time tool (sub-100ms budgets);
  inventory onboarding / supply-path curation / fraud / clearance.
- verify_trademark differentiator foregrounded: registries can't tell
  you authorized use cases or licensee posture.
- Deployment model section added: AAO-hosted as managed service for
  most members; self-hosted for holdcos/agencies with bandwidth; no
  brand-agent as graceful-degradation path.
- End-to-end Nike worked example added — six steps from discovery
  through full portfolio verification with cache guidance.
- Caching as normative SHOULD per-status (was prose).
- Rate-limiting as normative expectation: Retry-After header,
  prefer-cached-prior over hard error.
- Prior art expanded: ads.txt for inventory authority (complementary),
  WHOIS/RDAP for domain registration (different layer), trademark
  registries (registration facts only). No direct equivalent today.
- check_competitive_relationship moved to "indefinitely deferred"
  (politically loaded; brands won't publicly enumerate enemies).
- Authorization-tier table promoted to single authoritative source;
  task pages refer back.
- Resolved-decisions section replaces Open Questions.

Task pages
- Parallelism fixed for RAG retrieval: each page inlines core content
  (trust model row-table, caching, error codes) rather than cross-
  referencing back to verify_subsidiary_claim. Cross-links remain for
  full normative detail.
- Each page adds Capability discovery snippet showing get_adcp_capabilities
  advertisement.
- Each page's CodeGroup includes a Response (error) example.
- verify_property "When to use" reframed away from bid-time.
- verify_trademark leads with the differentiator vs registries.

Nav and Conformance
- docs.json: new Proposals group under brand-protocol nav surfaces the
  RFC.
- brand-json Conformance bullet updated to cite the correct signing
  key (response-signing) and call out that signed disputed/not_ours
  overrides leaf-side house_domain claims.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ify aging contract enforcement

Two pieces of feedback addressed.

Verification as a gate, not a signal
- verify_property and verify_subsidiary_claim now lead with "this is a
  prerequisite gate — check before you proceed, not after." The gating
  semantics are what justify the round-trip cost; consuming the answer
  post-decision means you're using the wrong tool.
- When-to-use sections reframed around gating points: inventory
  onboarding (gate the catalog entry), creative clearance (gate
  approval), fraud escalation (gate the action), brand-relationship
  establishment (gate governance trust extension).
- verify_trademark already framed correctly; minor lead tightening.

pending_review aging contract honesty
- MUST language stays — declared intent + defined fallback is better
  than today's silent pending limbo. But the enforcement story now
  reads as it actually is: agent-side, not spec-level. Most brand-side
  day-one deployments won't ship automated pending→unknown flipping.
- New dedicated subsection in the RFC: "pending_review aging and the
  crawl safety net." Spells out: enforcement is agent-side; day-one
  deployments will lag; consumer-side fallback to crawl on stale
  pending_review IS the safety net; MUST is fine because the fallback
  is graceful.
- Trust-model row updated to instruct consumers to treat stale
  pending_review as effectively unknown.
- Resolved-decision #2 points at the new section.
- verify_subsidiary_claim task page mirrors the same framing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…_property request

Platform-agnosticism lint flagged the store enum in
brand/verify-property-request.json (apple/google/amazon/roku) because
the new file path doesn't match the existing brand.json allowlist
entries. Same canonical-identifier justification applies: these are
the names of the app stores, not vendor-promotional values.

Factoring the store enum into a shared enums/property-store.json
(referenced from both brand.json and the verify_property request) is
the right long-term cleanup — protocol-expert review flagged it on
PR #4540. Tracking separately; for now the allowlist mirrors the
existing brand.json pattern.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…, not agent-replaces

Bokelley caught a real trust-model hole on PR #4540: as drafted, "the
agent wins" let a malicious or mistaken house claim subsidiaries it
doesn't own by returning `owned` to verify_subsidiary_claim without
the leaf reciprocating. The mutual-assertion floor was the exact
protection being bypassed.

The fix is to recognize the trust model is asymmetric by direction:

Rejection direction (agent wins unilaterally)
  agent says `disputed` / `not_ours` → authoritative. A brand has
  standing to refuse association regardless of what any other party
  publishes. Worst case is a brand denying a relationship it actually
  has — that's the brand's prerogative.

Assertion direction (mutual assertion still required)
  agent says `owned` / `pending_review` / `transferring` → informative
  but NOT trust-extending on its own. The leaf must still reciprocate
  via its `house_domain` claim (or its own brand-agent) before
  relationship trust extends. The agent provides real-time confirmation,
  richer states the crawl can't express, and signed authenticity — but
  it does NOT replace the mutual-assertion check.

Without this asymmetry, a malicious house unilaterally claims
subsidiaries and consumers extend trust on signature alone. Mutual
assertion exists precisely to prevent this.

Changes
- brand-json.mdx Conformance bullet: framing changed from
  "agent-preferred" → "agent-augmented." Split the override semantics
  by direction: rejection overrides leaf, assertion does NOT.
- RFC Trust model section: rewritten with two tables (rejection and
  assertion), explicit malicious-house scenario walkthrough, single
  "Mutual assertion remains the trust floor for positive trust
  extension" thesis statement.
- RFC Resolved-decisions #3: clarify "agent wins" applies to
  rejection direction only.
- verify_subsidiary_claim task page: trust-model table split into
  rows that condition on whether the leaf reciprocates. The
  agent's `owned` without reciprocation is now explicitly NOT
  trusted.
- verify_property task page: same asymmetric framing. Assertion-side
  requires cross-check against `brand.json` `properties[]` plus
  DNS/TLS evidence of control over the identifier.
- verify_trademark task page: same. Assertion-side requires
  registry record; agent is authority over licensee posture and use
  cases, not over registration ownership.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… out-of-scope

Bokelley flagged on PR #4540: verify_trademark returns licensed_in /
licensed_out because these relationships are real (Marriott franchisees,
music catalog licensing, jurisdictional rights splits — "I licensed my
catalog to someone in CN, manage it myself everywhere else"). But
brand.json doesn't have a publishing surface for standing licensed
relationships parallel to brand_refs[] for ownership.

The rights protocol (rights_agent + acquire_rights) handles transactional
licensing — negotiate a deal — not standing declarations like "I license
the MARRIOTT mark from Marriott Corp in DE, FR" or "I've granted Acme
Distribution rights to my catalog in CN."

This is a real protocol gap, too big to close in this RFC. Naming it
explicitly as out-of-scope so future readers don't think the omission
was accidental, and so the verify_trademark answers carry the right
caveat: the licensed states come from the brand-agent's internal
records, not from a crawlable static-file declaration.

Follow-up issue tracks the design: likely needs licensed_from[] /
licensed_to[] on the brand definition with jurisdictional scoping,
mutual-assertion shape parallel to brand_refs[], and integration with
the rights protocol's available_uses / right_types vocabulary.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs.json has two copies of the brand-protocol Tasks group (top-level
nav and the platform-builder reading-path nav). My earlier consolidation
commit caught the first copy via replace_all but the second has
different indentation, so the per-dimension entries lingered. Brian
caught it on review.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…rification surface

Ships the unified verification tool as a normative spec, not a proposal.
The PR is the WG-facing proposal; the docs are the shipping artifact.

Folds load-bearing RFC content into brand-json.mdx:
- New "Agent-augmented verification" subsection under Mutual-assertion
  trust model. Carries the direction-asymmetric trust table (rejection
  unilateral, assertion mutual-required) and the agent-to-agent mutual
  assertion path for when both sides publish brand-agents.
- Self-healing section updated: agent path is no longer a "planned
  follow-up" but the documented alternative to email when brand-agents
  are advertised.
- Conformance bullet drops "(proposed)" framing; cites the new
  subsection.
- Out-of-scope adds the standing-licensed-relationships gap as a
  fourth bullet — the licensed_in/licensed_out states are real and
  surfaceable via the agent, but the static brand.json publishing
  surface for them is a future RFC alongside the rights-protocol team.

Task page (verify_brand_claim):
- Drops the <Warning> "Proposed (RFC)" callout.
- Aging-contract prose moved inline (was a link to a deleted RFC
  section); content unchanged — agent-side enforcement, consumer-side
  fallback to crawl on stale pending_review.
- Cross-references to the RFC replaced with cross-references to
  brand-json.mdx § Agent-augmented verification.
- Authorization tier table no longer claims the RFC is the
  "authoritative" source — the task page stands on its own.

Cleanup:
- docs/brand-protocol/proposals/brand-verification-rfc.mdx deleted.
- Proposals nav group dropped from docs.json.
- Changeset renamed brand-verification-rfc.md → verify-brand-claim.md;
  rewritten from "Draft RFC" framing to minor-bump ship framing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>